IBIS Macromodel Task Group Meeting date: 23 April 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to work on BIRD197.3 draft3 to address Fangyi's comments. - Done. Ambrish sent two revisions to the ATM list. - Mike L. to send draft6 of the BIRD198 reply to meeting attendees. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 16 meeting. Mike L. moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: Response to JEITA authors of BIRD198: Mike L. shared the draft 6 he had emailed to the attendees of the previous meeting. Arpad reviewed three concerns he had raised in an email reply. Two of them were editorial in nature, and Mike made the changes. Arpad's third concern was related to the use of "rail" in the reply. He noted that "rail" in the BIRD189 context was used to distinguish power or ground from signal (I/O). But in this reply "rail" seemed to refer strictly to the power/ground buses defined by [Pin Mapping]. Mike agreed, and addressed the issue by changing "rails" to "supply rail buses" in two locations. Bob noted that the underlying assumption is that BIRD198 doesn't make sense unless you have [Pin Mapping], because that's the only way you can document the connection of a supply rail to a buffer. Arpad asked if further review was required. Bob moved that we should send the response. Mike seconded. There were no objections. Mike asked if he should send it or Arpad should send it. Arpad said Mike could send it because he had worked on it and had been part of earlier email discussions with the authors. Mike took an AR to send the reply, on behalf of Mike and Arpad, to the authors of BIRD198. BIRD197.3_draft_3.1 (DC_Offset): Arpad shared Ambrish's latest draft and suggested we could review it and provide Ambrish with a list of proposed changes. Arpad noted concerns he had with the language regarding AMI_Init() and AMI_GetWave() returning values of the parameter. He noted that in the previous meeting Fangyi had recommended that only the value returned by AMI_Init() be used. Arpad asked if a GetWave only model with no algorithmic information in its AMI_Init() could return a proper value from AMI_Init(). Fangyi said the model should be able to return the correct DC_Offset from AMI_Init(). He recommended that we not consider using values returned by GetWave(). He noted that this would lead to further complications such as, "Do you use the value returned by the first call to AMI_GetWave() or the value returned by the first call after the Ignore_Bits count has been exceeded?" Michael Mirmak asked if DC_Offset was something that could be computed up front based solely on the channel, or if it could change after each block, for example capacitive charge up. Fangyi said that if it was something like capacitive charge up, then that charge up time should be built into Ignore_Bits. Radek and Curtis noted that by definition all Out and InOut parameters are returned by calls to AMI_Init() or AMI_GetWave(). So, it's not necessary to explicitly state that the model could modify DC_Offset (an InOut) and return it. Curtis noted language from section 10.6 that states that for certain Jitter and Noise parameters the EDA tool should only use the value returned by AMI_Init(). He suggested we could adopt similar language for DC_Offset. The group agreed to suggest Ambrish look into this possibility. Fangyi expressed concern about ambiguity in this sentence: It is also assumed that the waveform input to the Rx AMI_GetWave function is the waveform minus this DC_Offset. Curtis noted that he had sent an email reply about this sentence after draft_1 was sent out. He noted that Walter's original sentence contained the modifier "single ended" in front of the second instance of "waveform", but "single ended" had been removed in draft_1. Fangyi suggested we add "physical" in front of the second instance of waveform. The group agreed, and Arpad made the change. Fangyi proposed the following sentence to explain the relationship between the Rx AMI_GetWave output waveform and DC_Offset: The physical waveform at the latch is the Rx AMI_GetWave output waveform plus the DC_Offset returned by the Rx AMI_Init function. Arpad added this change too. The group made other clarifications to the text. Arpad captured the changes as draft_3.2 and took the AR to send it to Ambrish and ATM. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Mike L. to send the response to the authors of BIRD198. AR: Arpad to send BIRD197.3 draft_3.2 to Ambrish and ATM. ------------- Next meeting: 30 April 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives